CM 
< 

CD 

o> 

CM 




Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 

(43) Date of publication: 

19.01.2000 Bulletin 2000/03 



(n) EP 0 973 296 A2 

EUROPEAN PATENT APPLICATION 

H04L 12/24 



(51) IntCI. 



(21) Application number: 99305462.6 

(22) Date of filing: 09.07.1999 



(84) 


Designated Contracting States: 


, Mandal, Kallol 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Fremont California 94555 (US) 




MC NL PT SE 


i Poggio, Andrew A. 




Designated Extension States: 


Palo Alto, California 94306 (US) 




ALLTLVMKRO SI 


i Bressler, Robert D. 

Los Altos Hills, California 94022 (US) 


(30) 


Priority: 17.07.1998 US 118361 






(74) Representative: 


(71) 


Applicant SUN MICROSYSTEMS, INC. 


Haines, Miles John et al 




Palo Alto, California 94303 (US) 


D. Young & Co. 
21 New Fetter Lane 


(72) 


Inventors: 


London EC4A1 DA (GB) 



CO 

| 

5 s 
cr 

CD 

O 

o 



(54) Controlling devices on a network through policies 



(57) A system that facilitates control over a 

group of devices coupled to a network. This system 
allows an operator to specify a policy for controlling 
a group of devices. This policy is automatically 
translated into lower-level device-specific commands, 
which are sent to the devices across the network. The 
system additionally provides a mechanism for continuous 
monitoring and control of the devices. Thus, one 
embodiment of the present invention provides a system 
for controlling devices on a network. This system 
operates by receiving a request to define a policy for 
controlling the devices. In response to the request, 
the system creates a policy object specifying actions 
of the devices to implement the policy, and stores the 
policy object in a memory. Next, the system associates 
the policy object with devices from the network, and 
controls these associated devices automatically 
according to actions specified in the policy object In 
one embodiment of the present invention, during 



creation of the policy object, the system translates 
the policy into device-specific commands for 
controlling the devices on the network, and associates 
the device-specific commands with the policy object. 
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BACKGROUND 
5 Field of the Invention 

[0001] The present invention relates to controlling devices across a computer network. More specifically, the 
present invention relates to providing an infrastructure that allows a user to specify a policy to govern the 
operation of devices coupled to a computer network. 

10 

Related Art 

[0002] In addition to facilitating communications between computer systems, computer networks are increasingly 
being used to facilitate communications between computer systems and electrical or mechanical devices such as 
is network routers, printers, facsimile machines, PBX systems, photocopiers and audio/visual equipment. For example, 
computer networks make it possible for computer systems to control and coordinate the actions of switching equipment 
in a PBX system, or to remotely control the operation of a routers in a computer network. 

[0003] However, the mechanisms being used to control such devices are presently very unsophisticated, which 
creates a number of problems for a system operator desiring to control a group of devices. First, devices are 

20 typically controlled by sending low-level device-specific commands to the devices. Thus, in order to control such 
devices a system operator must learn these low-level device-specific commands. Second, devices are typically 
controlled individually. Hence, in order to control a group of devices, a system operator must explicitly send 
commands to individual devices in the group. This can be a time-consuming process. Third, different devices are 
typically controlled through different management interfaces. Hence, a system operator must use a number of 

25 different management interfaces to operate a group of devices. Finally, present systems do not provide automated 
mechanisms to control and monitor the actions of devices. Consequently, a system operator must manually monitor and 
control the devices in order to accomplish a task requiring periodic monitoring and control. 

[0004] What is needed is a system that provides high-level control over a group of devices coupled to a computer 
network. 

30 

SUMMARY 

[0005] One aspect of the present invention provides a system that facilitates high-level control over a group of 
devices coupled to a computer network. This system allows an operator to specify a high-level policy for controlling 

35 a group of devices. This high-level policy is automatically translated into lower-level device-specific commands, 
which are sent to the devices across the computer network. The system additionally provides a mechanism for 
continuous monitoring and control of the devices. Thus, one embodiment of the present invention provides a system 
for controlling devices on a network. This system operates by receiving a request to define a policy for controlling 
the devices. In response to the request, the system creates a policy object specifying actions of the devices to 
implement the policy, and stores the policy object in a memory. Next, the system associates the policy object with 
devices from the network, and controls these associated devices automatically according to actions specified in the 
policy object. In one embodiment of the present invention, during creation of the policy object, the system 
translates the policy into device-specific commands for controlling the devices on the network, and associates the 
device-specific commands with the policy object 

^ [0006] Further aspects of the invention are exemplified by the attached claims. 

BRIEF DESCRIPTION OF THE FIGURES 

[0007] FIG. 1 illustrates a system including computers and devices coupled together through a network in 
accordance with an embodiment of the present invention. 
50 [0008] FIG, 2 illustrates the internal structure of a policy server for controlling devices on a network in 
accordance with an embodiment of the present invention. 

[0009] FIG. 3 illustrates the internal structure of a database system that stores dynamic entries specifying 
actions for devices on a network in accordance with an embodiment of the present invention. 

[0010] FIG. 4 is a flow chart illustrating the process of creating a policy for controlling devices on a network 
55 in accordance with an embodiment of the present invention. 

[0011] FIG. 5 is a flow chart illustrating the process of modifying a policy in accordance with an embodiment of 
the present invention. 
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[0012] FIG. 6 is a flow chart illustrating the process of monitoring devices in accordance with an embodiment of 
the present invention. 

[0013] FIG. 7 is a flow chart illustrating the process of deleting a policy in accordance with an embodiment of 
the present invention. 

5 [0014] FIG. 8 is a block diagram illustrating an example of controlling devices that route data across a network 
in accordance with an embodiment of the present invention. 

DETAILED DESCRIPTION 

10 [0015] The following description is presented to enable any person skilled in the art to make and use the 
invention, and is provided in the context of a particular application and its requirements. Various modifications to 
the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined 
herein may be applied to other embodiments and applications without departing from the spirit and scope of the 
present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be 

15 accorded the widest scope consistent with the principles and features disclosed herein. 

Description of System 
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[0016] FIG. 1 illustrates a system including computers and devices coupled together through a network 108 in 
accordance with an embodiment of the present invention. The system illustrated in FIG. 1 includes network 108, which 
is coupled to clients 102, 104 and 106 as well as servers 118 and 120. Network 108 is additionally coupled to 
devices 130 and 132 and policy server 122. 

[0017] . Network 108 generally refers to any type of wire or wireless link between computers and devices, 
including, but not limited to, a local area network, a wide area network, or a combination of networks. In one 
embodiment of the present invention, network 108 includes the Internet In the embodiment illustrated in FIG. 1, 
network 108 includes backbone 114, server network 116 and access networks 110 and 1 12. . 
[0018] Access networks 1 10 and 1 12 may include any type of network that can be used to couple client computing 
systems 102, 104 and 106 with network 108. This includes, but is not limited to local area networks. More 
specifically, access network 110 couples clients 102 and 104 with backbone 114, and access network 112 couples 
client 106 to backbone 114. 

[0019] Backbone 114 includes switching and routing devices that facilitate communications between server 
network 116 and access networks 110 and 112. This includes, but is not limited to, local area networks and wide area 
networks. For example, backbone 114 may include the Internet. The switching and routing devices in backbone 1 14 are 
denoted by boxes containing X's, and can be controlled by commands sent from computer systems coupled to network 
108. 

[0020] Server network 116 couples backbone 114 with servers 118 and 120 as well as devices 130 and 132. 
Server network 116 similarly contains switching and routing devices denoted by boxes containing X's that can be 
controlled by commands from computer systems coupled to network 108. Server network 116 may be any type of 
network coupled to a server computer system. For example, server network 116 may include a network supported by an 
Internet Service Provider (ISP)- 

[0021] Clients 102, 104 and 106 may include any node on a computer network including computational capability 
and including a mechanism for communicating across network 108. For example, clients 102, 104 and 106 may include 
a Java™ workstation or a personal computer running an internet browser. 

[0022] Servers 118 and 120 may include any node on a computer network including computational capability, and 
possibly data storage capability, as well as a mechanism for servicing requests from clients for computational or 
data storage resources. More specifically, server 118 is a file server that services requests for file accesses 
using the Network File System (NFS) protocol, and server 120 is a database server that services requests for 
database operations. 

[0023] Devices 130 and 132 may include any device that can be controlled by commands sent over a computer 
network. This includes, but is not limited to, a printer, a facsimile machine, a PBX telephone exchange, a 
photocopier, or audio/visual equipment, such as a digital camera. Note that although devices 130 and 132 are 
illustrated as being coupled to server network 116, they may generally be coupled to any location on network 108. 
[0024] Policy server 122 receives commands from user 126 through Graphical User Interface (GUI) 124, and uses 
these commands to control the actions of devices coupled to network 108. As illustrated in FIG. 1, policy server 122 
includes processor 121 and memory 123, which are used to carry out the actions of policy server 122. 
55 [0025] The system illustrated in FIG. 1 operates as follows. First, user 126 inputs commands into GUI 124; these 
commands specify a high-level policy for controlling actions of devices 130 and 132. For example, a policy may 
specify that a temperature control system should keep a portion of a building at a certain temperature. Another 
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policy may specify that a network management system should allow no more than 30% of total bandwidth for video 
traffic. Yet another policy may specify that a network management system should give higher priority to traffic on a 
LAN that originates from a finance server at the end of a quarter. Next, policy server 122 receives these commands 
and translates them into low-level device-specific commands that are sent to devices 103 and 132 across network 108. 
5 Note that policy server 122 may additionally be used to control switching and routing devices within backbone 114 
and server network 116. 



Description of Policy Server 

[0026] FIG. 2 illustrates the internal structure of a policy server 122 from FIG. 1 in accordance with an 
embodiment of the present invention. As in FIG. 1, policy server 122 receives policies from user 126 through GUI 
124. These policies are translated into lower-level device specific commands that are sent over network 108 to 
devices 130 and 132 (illustrated in FIG. 1). Policy server 122 receives requests to create policies 202 and 204, 
through HTTP protocol interface 206, or LDAP protocol interface 208. HTTP protocol interface 206 contains 
computational resources to decipher commands in the HTTP protocol. LDAP protocol interface 208 contains 
computational resources for deciphering commands in the LDAP protocol. 

[0027] Policy server 122 additionally contains directory 210, which is a data storage area that can be used to 
store dynamic entries, which specify parameters for different policies. In one embodiment of the present invention, 
directory 210 additionally stores conventional static database entries containing static data. 

[0028] Storing a dynamic entry in directory 210 causes policy factory 250 to create a corresponding policy 
object, which is stored in policy storage area 220. In the illustrated embodiment, policy storage area 220 contains 
policy objects 221, 222, 223, 224, 225 and 226. In one embodiment of the present invention these policy objects 
includes objects defined within an object-oriented programming system, which include data and methods that can be 
invoked to implement the associated policy. 

[0029] Policy objects 221, 222, 223, 224, 225 and 226 communicate with devices through device Policy 
Programming Interface (device PPl) 230. Device PPI 230 provides a uniform interface for communicating with devices 
across network 108. To this end, device PPI 230 includes a number of adapters for communicating with different 
devices using device-specific protocols. In general, device PPI 230 includes a different adapter for each different 
type of device it communicates with. More particularly, device PPI 230 includes: device adapter 231 for 
communicating with NFS devices; device adapter 233 for communicating with database devices; and device adapter 
235 for communicating with web server devices. As illustrated in FIG. 2, device PPI 230 can additionally communicate 
directly across network 108 through communication link 236. 

[0030] Device adapters 231, 233 and 235 include device objects 232, 234 and 236, respectively. Device objects 
232, 234 and 236 contain data and methods that can be used to communicate with associated devices over network 
1 08. These device objects are created by device factory 250 as is described below. 

[0031] Policy server 122 additionally includes topology service 260, which keeps track of the devices and 
computing nodes that are coupled to network 108. This information allows policies within policy server 122 to adapt 
to changes in the topology of network 108. 



Description of Database System 

[0032] FIG. 3 illustrates a database system that stores dynamic entries specifying actions of devices on network 
108 in accordance with an embodiment of the present invention. In one embodiment of the present invention, this 
database system is used to implement directory 210 from FIG. 2. The information stored in the directory is composed 
of directory of entries. Each entry is made up of attributes, wherein each attribute includes a type and one or more 
values. The type of attribute that is present in a particular entry is dependent on the class of object the entry describes. 
[0033] FIG. 3 illustrates a directory structured in the form of a tree, with vertices representing the entries. 
Entries higher in the tree (nearer the root) represent objects such as countries or organizations, whereas entries 
lower in the tree represent people or application-specific objects. Entries can include a distinguished name, which 
uniquely identifies the entry. The distinguished name of an entry could be made up of the distinguished name of its 
superior entry together with specially nominated attribute values from the entry. 

[0034] In one embodiment of the present invention, the Lightweight Directory Access Protocol (LDAP) is used the 
access the directory. The LDAP directory enforces a set of rules to ensure that the database remains well-formed in 
the face of modifications over time. These rules, known as the LDAP directory schema, prevent an entry from having 
the wrong types of attributes for its object class. They also prevent attribute values from being of the wrong form 
for the attribute type, and even prevent entries from having subordinate entries of the wrong class. 
[0035] In order to implement the present invention, the LDAP directory is extended to contain statements of 
dynamic behavior about devices coupled to network 108. These statements of dynamic behavior are referred to as 
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policies. Entries that represent policies are different from conventional directory entries in that they have a special 
class or schema definition to represent them. An LDAP directory entry that includes a policy requires more than 
standard functions for storage and retrieval. It requires a function that takes actions that are dictated by the 
attributes of the policy entry. 

5 [0036] As is illustrated in FIG. 3, the directory structure includes a root node 300, which is coupled to 
entries 302 and 304. Entry 302 is coupled to entries 306 and 308. Entry 306 is coupled to entry 310. These entries 
contain conventional static data. More importantly, entry 304 is coupled to policy root object 312. Policy root 
object 312 forms the root of a tree that contains policy entries. In the example illustrated in FIG. 3, policy root 
object 312 is coupled to policy entries 314 and 316. 

10 [0037] As illustrated in FIG. 3, policy entry 316 includes attributes 317, 318 and 319. Each policy attribute 
contains a type and values. For example, policy attribute 317 includes type 320 and values 322. 

Description of Policy Creation Process 

[0038] FIG. 4 is a flow chart illustrating the process of creating a policy for controlling devices in 
accordance with an embodiment of the present invention. The process starts when the system receives a request to 
create at policy (state 402). In one embodiment of the present invention, the request is received from user 126 who 
inputs the request into a web browser operating on GUI 124. The request can be received in a number of ways. In one 
embodiment of the present invention, the system receives the policy creation request through HTTP protocol interface 
206. In another embodiment of the present invention, the system receives the request through LDAP protocol interface 
208. 

[0039] The system next adds an entry for the requested policy in directory 210 within policy server 122 (state 
404). This entry contains attributes specifying the policy. Next, a corresponding policy object is created by policy 
factory 240 (state 406), and the policy object is stored in policy storage area 220. This policy object contains 
data and methods for controlling devices on network 108 to implement the policy. In one embodiment of the present 
invention, the object is created within the Java™ programming language based upon the Java™ class path of the 
policy. 

[0040] Next, the policy object performs a lookup in directory 210 to verify that the object has been created 
consistently with the associated parameters contained within the corresponding entry in directory 200 (state 408). 
Next, the object acknowledges that it has been created successfully by sending a message to user 126 through GUI 
124 (state 410). 

[0041] The policy object next fetches a list of devices that compose the policy domain from topology service 260 
(state 412). Topology service 260 maintains status information for the active devices coupled to the network by 
either periodically polling devices on network 108, or by merely listening to traffic on network 108 to determine 
which devices are responding to commands, and are hence, "active." During this process, topology service 260 updates 

35 the corresponding policy entry in directory 210 to reflect and changes in the policy domain. Once the policy object 
knows the status of devices, it can select devices to implement the policy from the policy domain. 
[0042] In order to communicate with and command the devices, the policy object fetches device object handles 
from device factory 250 (state 414). Next, the policy object uses the device object handles to communicate with the 
devices in order to establish and monitor the policy according to the policy schedule (state 416). This involves 

40 communicating with the devices through device PPl 230 and device objects 232, 234 and 236, as well as device 
adapters 231 , 233 and 235. 

[0043] Finally, the policy object updates its corresponding entry in directory 210 to indicate the status of the 
policy (state 418). This information includes a list of the devices involved in implementing the policy as well as. 
status information for the devices and the policy. This updating process occurs periodically while the policy is 
executing, so that the corresponding entry in directory 210 is continually updated. 

[0044] The above states are repeated for each additional policy object that is created by the system illustrated 
in FIG. 2. 
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Description of Policy Modification Process 



[0045] FIG. 5 is a flow chart illustrating the process of modifying an existing policy in accordance with an 
embodiment of the present invention. The process starts when the system receives a request to modify an existing 
policy (state 502). In one embodiment of the present invention, the request is received from user 126 who inputs the 
request into a web browser operating on GUI 124. Next, the system modifies the entry for the policy within directory 
55 210, so that the directory properly indicates the modified state of the policy (state 504). Next, the system 
modifies the policy object by sending a change request to policy factory 240 (state 505). Policy factory 240 relays 
this request to the policy object, which makes the requested change. Next, the policy object performs a lookup in 
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directory 210 to verify that the policy object has been modified consistently with the associated parameters 
contained within the corresponding entry in directory 200 (state 508). Next, the policy object acknowledges that it 
has been modified successfully by sending a message to user 126 through GUI 124 (state 510). The above process is 
repeated whenever a policy is modified. 

5 

Description of Device Monitoring Process 

[0046] FIG, 6 is a flow chart illustrating the process of monitoring devices involved in a policy in accordance 
with an embodiment of the present invention. The process starts when the system receives a request to monitor an 

10 existing policy (state 602). In one embodiment of the present invention, the request is received from user 126 who 
inputs the request into a web browser operating on GUI 124. Next, the system reads policy status information from 
the entry for the policy in directory 210 (state 604). Recall that the entry for the policy in directory 210 is 
periodically updated with status information regarding the policy. Next, the system returns the policy status 
information to the requestor. In one embodiment of the present invention, this status information is returned in the 

15 form of HTML data, which contains Java™ applets. These Java™ applets query the policy object for private policy 
status information. The above process is repeated whenever a request for policy status is received. 

Description of Policy Deletion Process 

[0047] FIG. 7 is a flow chart illustrating the process of deleting a policy in accordance with an embodiment of 
the present invention. The process starts when the system receives a request to delete an existing policy (state 702) 
. In one embodiment of the present invention, the request is received from user 126 who inputs the request into a 
web browser operating on GUI 124. Next, the system initiates the removal process (state 704). This is accomplished 
by sending a removal request to policy factory 240. Policy factory 240 looks up the corresponding policy object and 
notifies the policy object that it is to be removed. The policy object then carries out the removal process and 
acknowledges that it has been successfully deleted by sending a message to user 126 through GUI 124 (state 706). 
Next, the system removes the entry for the policy from directory 210 (state 708). The above process is repeated 
whenever a policy is modified. 

Example 

30 

[0048] FIG. 8 is a block diagram illustrating the process of controlling devices that route data across a 
network in accordance with an embodiment of the present invention. In the example illustrated in FIG. 8, policy 
server 122 (from FIG. 1) controls the actions of a number of devices, including server 118, switch 802, router 804, 
router 805, switch 806 and client 808. Switches 802 and 806 forward packets at the medium access control level, and 
35 routers 804 and forward packets at the Internet protocol level for communication across network 108 in FIG. 1. 

[0049] In order to communicate with the illustrated devices, policy server 122 includes a number of adapters, 
including NFS adapter 812 for communicating with server 118, router adapter 814 for communicating with routers 804 
and 805, and switch adapter 816 for communicating with switches 802 and 806. 

[0050] In the configuration illustrated in FIG. 1, policy server 122 can implement a number of policies related 
40 to controlling network traffic between server 118 and client 808. For example, one policy might be to reserve 5 
megabits of bandwidth from server 118 to client 808. To implement this policy, policy server 122 sends commands to 
the illustrated devices from left to right in FIG. 8 starting at server 118 and proceeding to client 808. These 
commands specify that 5 megabits of bandwidth should be reserved for traffic between server 118 and client 808. The 
reason policy server 122 starts on the server side of the network is that network traffic tends to be concentrated 
45 nearer to file servers, and devices that are closer to the file servers tend to include more sophisticated 
mechanisms to manage traffic. 

[0051] The foregoing descriptions of embodiments of the invention have been presented for purposes of 
illustration and description only. They are not intended to be exhaustive or to limit the invention to the forms 
disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. 
50 Additionally, the above disclosure is not intended to limit the invention. 

Claims 

1. A method for controlling devices on a network, comprising: 



55 



receiving a request to define a policy specifying a behavior for controlling the devices on the network; 
creating a policy object specifying actions of the devices on the network to implement the policy; 
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storing the policy object in a memory; 

associating the stored policy object with at least one device from the devices on the network; and 

5 

controlling the at least one device in accordance with the stored policy object in order to implement the policy. 

2. The method of claim 1, wherein the act of creating the policy object includes translating the policy into device- 
10 specific commands for controlling the devices on the network, and associating the device-specific commands with 

- the policy object. 

3. The method of claim 2, wherein the act of controlling the at least one device includes communicating the device- 
specific commands across the network to the at least one device. 
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4. The method of claim 1, 2 or 3, wherein the act of controlling the at least one device includes monitoring a 
status of the at least one device. 



5. The method of any preceding claim, wherein the act of controlling the at least one device includes performing a 
20 sequence of actions over a period of time to implement the policy without human intervention. 

6. The method of any preceding claim, wherein the act of controlling the at least one device includes performing a 
sequence of actions that are specified in relation to a time base. 

25 7. The method of any preceding claim, further comprising determining which devices are active on the network. 

8. The method of any preceding claim, wherein the act of storing the policy object in the memory involves storing 
the policy object in a database. 

3 0 9. The method of any preceding claim, wherein the act of storing the policy object in the memory involves storing 
the policy object in a random access memory. 

10. The method of any preceding claim, wherein the policy object includes an object defined within an object- 
oriented programming system. 



1 1 . The method of any preceding claim, wherein the devices respond to different device-specific commands. 

12. The method of any preceding claim, wherein the at least one device includes a router for routing traffic over 
the network. 

13. A method for controlling devices on a network, comprising: 

receiving a request to define a policy specifying a behavior for controlling the devices on the network; 

creating a policy object specifying actions of the devices on the network to implement the policy, including 
translating the policy into device-specific commands for controlling the devices on the network, and 
associating the device-specific commands with the policy object; 

storing the policy object in a memory; 

associating the stored policy object with at least one device from the devices on the network; and 

controlling the at least one device in accordance with the stored policy object in order to implement the 
policy by communicating the device-specific commands across the network to the at least one device, and 
monitoring a status of the at least one device. 



14. A computer readable storage medium storing instructions that when executed by a computer cause the computer 
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to perform a method for controlling devices on a network, comprising: 

receiving a request to define a policy specifying a behavior for controlling the devices on the network; 
creating a policy object specifying actions of the devices on the network to implement the policy; 
storing the policy object in a memory; 

associating the stored policy object with at least one device from the devices on the network; and 
controlling the at least one device in accordance with the stored policy object in order to implement the policy. 



15. A computer instruction signal embodied in a carrier wave carrying instructions that when executed by a computer 
15 cause the computer to perform a method for controlling devices on a network, comprising: 

receiving a request to define a policy specifying a behavior for controlling the devices on the network; 

creating a policy object specifying actions of the devices on the network to implement the policy; 

20 

storing the policy object in a memory; 

associating the stored policy object with at least one device from the devices on the network; and 
25 controlling the at least one device in accordance with the stored policy object in order to implement the policy. 

16. A system that uses policies to control devices on a network, comprising: 

30 a policy server coupled to the network; 

a request receiving mechanism, within the policy server, that receives a request to define a policy 
specifying a behavior for controlling the devices on the network; 

35 a policy creation mechanism, within the policy server, that creates a policy object specifying actions of 

the devices on the network to implement the policy; 

a memory, in communication with the policy creation mechanism, that stores the policy object; and 

4Q an execution mechanism, within the policy server, that controls the devices in accordance with the stored 

policy object in order to implement the policy. 



17. The system of claim 16, wherein the policy creation mechanism translates the policy into device-specrfic 
commands for controlling the devices on the network, and associates the device-specific commands with the policy 
object. 

18. The system of claim 17, wherein the execution mechanism is configured to communicate the device-specific 
commands across the network to devices. 

19. The system of claim 16, 17 or 18, wherein the execution mechanism is configured to monitor status of devices on 
the network. 

20. The system of any one of claims 16 to 19, wherein the execution mechanism is configured to perform a sequence 
of actions over a period of time to implement the policy without human intervention. 

21 . The system of any one of claims 16 to 20, wherein the execution mechanism is configured to perform a sequence 
of actions that are specified in relation to a time base. 
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22. The system of any one of claims 16 to 21, further comprising a device finding mechanism that determines which 
devices are active on the network. 

5 23. The system of any one of claims 16 to 22, wherein the memory includes a database, 

24. The system of any one of claims 16 to 23, wherein the memory includes a random access memory. 

25. The system of any one of claims 16 to 24, wherein the policy object includes an object defined within a object- 
to oriented programming system. 

26. The system of any one of claims 16 to 25, wherein the devices respond to different device-specific commands. 

27. The system of any one of claims 16 to 26, wherein the devices include a router for routing traffic over the network. 
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